The Internet Protocol Multimedia Subsystem (“IMS”) is an architectural framework for delivering Internet Protocol (“IP”) multimedia to mobile users, such as users of mobile devices like smart phones or tablet computers. An IMS core network (“IMS core”) permits wireless and wireline devices to access multimedia, messaging, and voice applications and services. IMS standards and specifications have been promulgated by the 3rd Generation Partnership Project (“3GPP” ™). To allow the IMS core to be integrated with Internet resources, the 3GPP specifications use Internet Engineering Task Force protocols within the IMS core, such as Session Initiation Protocol (“SIP”) and Diameter. SIP is a signaling protocol used for creating, modifying and terminating two-party or multiparty sessions consisting of one or several media streams. A mobile device registers its IP address with a SIP registrar server within an IMS core by generating and sending a SIP request message with a “REGISTER” method token. Once registered, a mobile device may subsequently establish multimedia sessions via the IMS core.
An IMS client (or IMS stack) software component on a mobile device allows one or more applications on the mobile device to register for various application services that are available on the IMS network. If the registration is successful, the mobile device application may then take advantage of the functionality offered by the application service to which it is registered. If the registration is unsuccessful, however, then the application will be unable to take advantage of the offered functionality. In cases where a requested registration fails, the requesting application may benefit from receiving a notification of the failure. In current systems, the requesting application may receive a generic notification that alerts the mobile device only that one or more registration failures have occurred—without providing an indication as to which specific service registration failed. This shortcoming leads to situations where one rejected application service triggers deregistration of all applications—even those applications that are not necessarily supposed to terminate. Moreover, in current systems, the generic notification may omit information describing the nature of or reason for the failure. The lack of information conveyed to the application on the mobile device means that it is unable to effectively assess what additional steps, if any, it should take in order register with the application service.
FIGS. 1A and 1B offer high level illustrations of the IMS application service registration procedure according to current systems. In FIG. 1A, Application 1 sends to the IMS client a request to register for an application service identified as ICSI_1 (step 1); Application 2 sends to the IMS client a request to register for an application service identified as ICSI_2 (step 2); and Application 3 sends to the IMS client a request to register for an application service identified as ICSI_3 (step 3). After receiving the service registration requests, the IMS client transmits all of the received registration requests to the IMS network (step 4), which returns an acknowledgement message to the IMS client (step 5). In step 6, the IMS network sends a registration request for the application service identified as ICSI_3 to Application Server 3 (which is associated with ICSI_3); in step 7, the IMS network sends a registration request for the application service identified as ICSI_2 to Application Server 2 (which is associated with ICSI_2); and, in step 8, the IMS network sends a registration request for the application service identified as ICSI_1 to Application Server 1 (which is associated with ICSI_1). After the IMS network sends each registration request to its associated application server, each respective application server returns to the IMS network an acknowledgment that indicates whether the registration succeeded or failed. For example, in step 9, Application Server 3 returns an “OK” acknowledgment to inform the IMS network that the registration succeeded; in step 10, Application Server 2 returns an “OK” acknowledgment to inform the IMS network that the registration succeeded; and, in step 11, Application Server 1 returns an “OK” acknowledgement to inform the IMS network that the registration succeeded.
Accordingly, FIG. 1A illustrates a successful registration flow in which each requested registration succeeded for each requested service. In practice, however, one or more requested registrations may fail. For example, FIG. 1B illustrates a registration flow identical to FIG. 1A with the exception that, in step 9, Application Server 3 returns a “NOK” acknowledgement. Unlike the “OK” acknowledgement in step 9 of FIG. 1A, the “NOK” acknowledgement in step 9 of FIG. 1B indicates that the registration for the application service identified as ICSI_3 has failed.
When such a failure occurs, the application that requested the registration may benefit from receiving a notification that the failure occurred. Accordingly, an application may subscribe to receive notifications indicating whether a requested registration is successful or unsuccessful. In practice, a single application may request registrations for multiple services. For example, a single application may request a registration to Service A, which ultimately succeeds; may request a registration to Service B, which ultimately succeeds; and may request a registration to Service C, which ultimately fails. In current systems, the application would be notified only that a failure was received; the application would not be notified as to which particular application service failed. In other words, the application would know that at least one application service failed, but the application would not know whether the failure occurred with respect to Service A, Service B, or Service C. As a result, the application would be forced to terminate all application services (i.e., the application would terminate Service A, Service B, and Service C) rather than terminating only the one service that failed (i.e., Service C). Moreover, in current systems, the application receives no reason for the failure. For example, the application does not know whether the requested registration failed because the mobile device user has not paid for access to the failed service, because a physical connection could not be established to the server associated with the requested service, or for a host of possible other reasons.